6題目批量生成系統跟主題標籤系統都落地之後，接下來就是要處理AI後台管理員—這個調閱後台數據、標籤題庫、使用者回饋；定時搜新聞找題材；定時調用生題功能；處理回饋跟UI改進的功能。

feedback-pipeline

在之前我就有設計過一個與後台管理員類似的功能，但跟skill一樣，有許多過時的功能不能直接取用，所以要先選擇哪些能用那些不能。

回饋表單
過往的回饋表單已經不足以支撐現有對於題目更換跟Bug修理的需求，要要更改之前的表單設計，並為了方便使用者改為常駐在程式中，分別重新設計一個可以收集使用者出題興趣的表單，跟一個負責回報程式BUG的表單。

後續會再決定具體的問題與涉及設計，今天專注於理清管理員與各功能的配合。

功能分流

管理員身為統籌的skill，底下功能：回饋分流、新聞找題材、生題三者觸發頻率跟風險等級差很多，塞同一個routine會讓prompt過度肥大。

既有feedback-triage就移轉成BUG回報線；生題routine全新、單一agent直接把整個流程做完，固定daily排程，彙整期間累積的回饋/新聞生出一天的量。

新聞搜尋功能

新聞搜尋的目的是保持最新資訊的題目來源，所以要尋找（以台灣地區為主）的最新新聞再將議題寫成題目。
該功能會與另外兩項在交付出題任務時水平給予關鍵詞，管理員後續需要自行判斷可能無關的幾個詞條要怎麼安排有限的題目量生成。

最終架構總覽

最後我們就能整理出一份架構，三條各自獨立排程的routine，共用同一套資料（Postgres＋APP常駐表單），彼此觸發頻率跟風險等級都不同。

BUG回報線
既有routine移轉·daily
沿用gsat-feedback-triage三層判斷邏輯
讀取來源從Google表單改成APP常駐BUG回報表
表單題目本身可能重新設計
抓到內容/標籤錯誤 → 觸發舊題退場

生題線
全新routine·daily
彙整回饋／題庫缺口／新聞三條題材，自行分配當天數量
單一agent從查證、寫題到batch-generate.ts寫入一次做完
標籤防重複/佔比flag自主裁決，不逐項確認
不走PR審核，開發者事後自行抽查

通知
隨①②執行後觸發
每次跑完寄一份摘要連結到開發者信箱
內容：新增幾題、涵蓋哪些標籤、裁決次數、退回的回饋
是抽查機制的前提——沒通知就不知道要查什麼

架構設計完明天就能實際開始跑了，連帶的優化功能也會一起在這次方案中上架。